Information Sheet
Develop a JDTA (with a focus on the structure of data)
Introduction:
When a needs assessment has indicated a training requirement, the ISD/SAT project planning has been completed, and the instructional system concept is approved, it is time to enter the analysis phase of instructional development. During this phase, instructional developers conduct various forms of analyses such as training situation, occupational, job, mission, and task analyses. These analyses continue through the selection of training tasks. The nature and scope of each ISD/SAT project determines which of the various analyses need to be conducted.
Information:
The E2E Process is all about defining the work. JDTA's should always be skill-based or at least based on the Application level or higher of Bloom's Taxonomy. In the JDTA, supporting Knowledge is addressed at the Task level by the KSATR's. Since CPM and AIM Learning Object (LO) Module are based upon the development of performance-based instruction, JDTA's are that foundation. As you move further into the E2E process, other features become available to help build effective training at any required instructional level. Some of these include:
CPM Projects - has the ability to change action verbs and the platform (platform, system, sub-system, component and non-equipment) field and add multiple different Content Types.
LO Module - Each Content Type is made up of elements, LO Module also has the ability to add additional element types and sub-elements to increase the designer / developers ability to address a wide range of instructional requirements.
NOTE: While you can take NAVEDTRA 130 Task-based items and move them over, we hope after you review the items below, that the risk of just coping data over without performing an analysis will be apparent. CPM/LO work very well if the proper analysis to define the work is done first. Short-cuts or taking an approach of just throwing data at the JDTA using an old 130-style approach normally causes the designer / developer to blame the tool for problems later in development. In all of the NAVEDTRA's, the designer / developers must always start with the highest level of skill and work backwards to ensure required material is being taught and assessed properly.
1. In the below graphics (Figure 1 to Figure 7) , if the JDTA was performed correctly, the following items would be different (see explainations next to each Figure 1 to 7) ......
The JDTA in CPM would be much more organized, (it might be shorter) and broken down using multiple duties, task, KSATR's, sub-task and steps.
The describe action (or any recall / comprehension) verb would almost never be used (name a job that someone "describes" something. They operate, evaluate, interrupt, analyze, estimate, perform, etc.... (just to name a few examples)
The JDTA would look like this ...... (not complete example, but a good start to sit down with a Sonar SME to complete) Compare with Figure 1.
Duty - Sonar
Task - Operate Sonar Equipment - KSATR - Knowledge = Different types of Arrays, Projectors, Hydrophones. Describe SONAR.
Below is some examples with explanation of bad JDTA's
Figure 1 - Example of a poorly constructed JDTA that is based on an existing course CTTL (knowledge only)An example of what this one would look like if done correctly can be found here.
Figure 2 - Example of a poorly constructed JDTA that should drop the "Duties to Task" and current "Task should be sub-task or KSATR"Besides being knowledge based, a task should never be describe or explain because that's not done on the job.
Figure 3 - A common mistake made by acquisition programs and when looking at multiple rates that perform the same jobs. It goes to life-cycle maintenance, leads to duplicate training being developed and is probable owned by the same Requirements Sponsor anyway. So ease the job analysis process by combining into one common task (Job could be CSCS Maintenance Rates). Since CPM can now link multiple JDTA's items together in the Projects tab this is less of a problem.
Figure 4 - Another common mistake is to try and force all of the JDTA work requirements into just the Duty and Task levels of CPM. Hopefully with the above example (SONAR) you will see how sub-task and KSATR's can be used to make this list more manageable.
Figure 5 - JDTA's are about the work, in this case the CRF Division Officer is probable "Managing the 3M program", SKED is a tool or "Manage the3M SKED" (other action verbs are possible). I doubt they are "Administer SKED, Administer Advanced Skills Management, etc....). This a good example of why the ISS (ISD/SAT/LSO) needs to be involved in the process. Based on this JDTA construct, a section (with an ELO) in Learning Object (LO) Module would be created and would prove very difficult to turn into effective training.
Figure 6 - Stay away from system/equipment specific names. "Operating the Ship Control Console" is just as effective as what is listed above. CPM in the Data Tab allows multiple platforms, systems, sub-systems, components, non-equipment and environment that can be used to allow these JDTA items to be used to support current and even future equipment vendors. If one maker has additional capabilities, you just add them to the list of job task. In CPM projects only select the ones that you will be training to support.
Figure 7 - A common mistake made by acquisition programs are the fact they focus on systems and equipment, not the work. Acquisition programs are required to complete a Job Task Analysis (JTA). Since multiple program offices might have similar requirements (operating a crane on CVN-68 class and operating a crane on LPD-17 is different and requires the Sailor to follow different procedures. But the people doing that work, the safety and foundational training is the same. The Learning Center / NETC are the only organizations that look across multiple acquisition programs. So it does require the Learning Center to adopt a plan of how JTA data gets migrated over to JDTA data. You can have multiple JTA's that link to a single JDTA based on a Sailor's rate.
^ Currently none of this information is found in the NAVEDTRA series. While not found in the NAVEDTRA series developers of JDTA should consider these concepts as lessons learned and examples when performing JDTA development. The NETC SOP at a high-level discusses this concept.
Develop a JDTA (with a focus on the structure of data)
Introduction:
When a needs assessment has indicated a training requirement, the ISD/SAT project planning has been completed, and the instructional system concept is approved, it is time to enter the analysis phase of instructional development. During this phase, instructional developers conduct various forms of analyses such as training situation, occupational, job, mission, and task analyses. These analyses continue through the selection of training tasks. The nature and scope of each ISD/SAT project determines which of the various analyses need to be conducted.
References:[1]
Information:
The E2E Process is all about defining the work. JDTA's should always be skill-based or at least based on the Application level or higher of Bloom's Taxonomy. In the JDTA, supporting Knowledge is addressed at the Task level by the KSATR's. Since CPM and AIM Learning Object (LO) Module are based upon the development of performance-based instruction, JDTA's are that foundation. As you move further into the E2E process, other features become available to help build effective training at any required instructional level. Some of these include:
NOTE: While you can take NAVEDTRA 130 Task-based items and move them over, we hope after you review the items below, that the risk of just coping data over without performing an analysis will be apparent. CPM/LO work very well if the proper analysis to define the work is done first. Short-cuts or taking an approach of just throwing data at the JDTA using an old 130-style approach normally causes the designer / developer to blame the tool for problems later in development. In all of the NAVEDTRA's, the designer / developers must always start with the highest level of skill and work backwards to ensure required material is being taught and assessed properly.
1. In the below graphics (Figure 1 to Figure 7) , if the JDTA was performed correctly, the following items would be different (see explainations next to each Figure 1 to 7) ......
NOTE: When building Learning Objectives (from JDTA) later in CPM Projects you can choose different Content Types (mix different ones together), change Action Verbs and use the Platforms option to address specific systems.
Below is some examples with explanation of bad JDTA's